Requirements in New Business Underwriting

The New Business Underwriting process may require several different types of requirements to be fulfilled before an applicant is able to open a policy with the company. These requirements could verify medical or financial factors surrounding the client, as well as the client's age, the product line of the policy for which they are applying, or the policy's face amount, among other possible requirements. In other scenarios, requirements may be dependent on the fulfillment of a predecessor requirement, or can be triggered by an amendment or Home Office Endorsement in the event that information on an application changes.

Because of the significant role that requirements play in the New Business Underwriting process, a number of business rules and other configuration tools exist in the Rules Palette to tailor the processing of requirements to specific business needs. This page outlines the configuration available for New Business Underwriting requirements.

See the Requirements folder in this help system for more information on creating and configuring requirements in general. Navigate to Admin Explorer | Requirements.

Configuration Foundation

Requirement configuration consists of three major building blocks: Requirement Detail configuration, Requirement Result configuration and Requirement Definition configuration. In OIPA, these building blocks control the Requirement user interface, the Requirement Result screen and the processing of the requirement, respectively. In the Rules Palette, each of these areas of configuration has its own configuration tab in the Requirement Editor.

The configuration for each of the building blocks is stored in the AsRequirementDefinition database table. A record must exist in this table in order for a requirement to exist, although requirements can have NULL values in the XMLData, XMLResult and/or XMLDefinition columns. Requirements may also be configured partially or entirely through CopyBooks.

RequirementDetail

Requirement Detail configuration controls OIPA's requirement user interface, including fields, events, actions and ScreenMath. This component is configured in the XMLDefinition tab of the requirement editor, and the configuration is stored in the XMLData column of AsRequirementDefinition.

For detailed information on configuring Requirement Details, navigate to Requirements | Requirement Detail in the XMLConfiguration Guide.

Requirement Result

Requirement result configuration controls the information that displays on the Requirement Result screen. Requirement results can be formatted in three ways:

  • Fields—Individual fields associated with an individual requirement result. These fields may be obtained from AsRequirementResult and AsRequirementResultField.
  • Text—A complete text document, which is stored in the ResultText column of AsRequirementResult.
  • Table—A table that contains data obtained from AsRequirementResultTypeField,

Requirement results may arrive electronically or in paper form, but regardless of the medium, a result must have a record in AsRequirementResult in order to be visible in the system. Depending on the format of a result (fields, text or table), additional records may be created in AsRequirementResultField, AsRequirementResultType and/or AsRequirementResultTypeField. Records do not need to be present in these additional tables for a result to be visible in OIPA.

If a result arrives electronically, its record will be inserted into AsRequirementResult via AsFile.

If the RequirementGUID of the ordering requirement is known when a result record is created, then the record is inserted into the AsMatchedRequirementResult database table. If the RequirementGUID is not known, then the result record is inserted into the AsUnmatchedRequirementResult database table.

Unmatched requirement results can be matched with requirements on the Activity Requirement screen in OIPA. To do so, a user should search for a requirement and click on the magnifying glass icon in the desired requirement's Action column, which will open the RequirementResult Search screen. The user can then search for a requirement result and, if the desired result is found, click on the page icon to match it to a requirement. The Requirement Result Search screen can be configured using the RequirementResultSearchScreen business rule.

Requirement Definition

Requirement definition configuration controls the processing of a single requirement. Requirement definitions are configured in the XMLSource pane of the requirement editor, and the configuration is stored in the XMLDefinition column of AsRequirementDefinition.

For detailed information on the configuration of requirement definitions, navigate to Requirements | Requirement Definition in the XMLGuide.

Supporting Configuration

Depending on the exact method by which a requirement is intended to process, some additional configuration may be necessary. An outline of additional configuration is provided below. Note that the NBU system will need to be enabled for the following configuration to be available.

  • The Application screen may need to be configured to allow requirements for a particular role on a policy.
  • Requirements whose availability should be dependent on the policy's status should be defined in the EligibleRequirementsByPolicyStatus business rule.
  • If the addition or processing of requirements needs to be triggered by other events in the system, additional business rules may need to be attached to a transaction or requirement:
    • AddRequirements: This business rule is attached to a transaction or requirement in order to add requirements based on the configured requirement criteria.
    • ProcessRequirements: This business rule is attached to a transaction in order trigger the processing of requirements.
    • CopyToPolicyFields: This business rule allows one or more MathVariables to be copied from an activity to one or more policy fields.
    • CopyToClientFields: This business rule allows one or more MathVariables to be copied from an activity to one or more client fields when the activity to which this rule is attached is processed.
    • CopyToRequirementFields: This business rule is attached to a transaction to allow the results of an activity’s math calculations to write out to a defined group of RequirementGUIDs.
    • MatchRequirementResult: This business rule matches a specified requirement result with the current requirement.
    • ProcessActivities: This business rule is attached to a requirement to set conditions for the automatic processing of activities.
    • SpawnActivities: This business rule is attached to a requirement or transaction to set conditions for the spawning of activities.
    • StatusChange: This business rule can use requirements as criteria for updating an application's status.
  • The UnmatchedResultSearchScreen can be used to configure the Unmatched Requirement Result Search screen. While specific requirement results can be matched to specific requirements using the MatchRequirementResult attached rule, this screen allows the user to perform a search for unmatched requirement results across all available policies, and then attach the results to requirements.